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5 

TECHNICAL FIELD 
The present invention relates to IP telephony and, more particularly, to 
enabling IP telephony users transparent access to features of a remote private 
automatic branch exchange (PBX) or similar equipment (centrex, KTS, EKTS or 
10 hybrid systems) offering features in addition to a telephone connection, which 
equipment is connected to the public switched telephone network (PSTN). 

DISCUSSION OF RELATED ART 
IP telephony is an efficient, economical and effective communications 
15 solution that enables voice and fax over IP networks. Many small and medium- 
sized enterprises are eager to deploy IP telephony technology and begin 
realizing the benefits of voice over IP (VoIP). 

However, many of these organizations rely upon proprietary private 
branch exchange (PBX) centrex. KTS, EKTS or similar equipment offering 
2 0 features In addition to a simple telephone connection to meet current 

telecommunications needs. Most have made a considerable investment in PBX 
or like equipment and are fully satisfied with the functional advantages it has to 
offer. Realizing the benefits of new IP telephony solutions in remote offices or for 
teleworkers is appealing, but the disruption and expense of changing an entire 

2 5 infrastructure is less than desirable. 

DISCLOSURE OF INVENTION 
An object of the present invention is to provide a bridging of IP telephony 
to the public switched telephone network and in particular to existing equipment 

3 0 offering features in addition to a simple telephone connection, such as PBXs, 

centrex or KTS systems. 
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According to a first aspect of the present invention, a metliod comprises 
the steps of connmunicating between an internet protocol (IP) device over an IP 
network and a bridge connected to non-IP equipment providing telephony 
connections as well as telephony-related features, which equipment is connected 
5 to a public switched telephone network (PSTN), by signaling from said IP device 
to said bridge with an access code indicative of a feature of said equipment and 
by converting said access code to a non-IP protocol for accessing said feature of 
said non-IP equipment by said IP device. 

In further accord with the first aspect of the invention, said signaling with 
10 an access code, a remote hookflash is signaled from said IP device to said 

bridge. The remote hookflash may be signaled from a non-IP device connected 
to said IP device. 

."i According to a second aspect of the present invention, a method for 

^ accessing a feature of equipment connected to a public switched telephone 

g 15 network with an access signal code corresponding to said feature, comprises the 

steps of initiating said access code signal from a terminal (22, 24, 26) remote 
M= from said equipment, transmitting said access code signal as a packetized signal 

over an internet protocol (IP) network to a relay device (10), and converting said 
packetized access code signal at said relay device to a non-IP access code 
Q 2 0 signal for said accessing said feature. 

In further accord with the second aspect of the invention, said method 
further comprises the steps of signaling from said terminal to said relay device 
with a packetized hookflash signal before said steps of initiating and transmitting 
said access code signal and converting said packetized hookflash signal at said 

2 5 relay device to a non-IP hookflash signal for signaling said equipment before 

accessing said feature with said access code signal. The hookflash signal and 
the access code may be signaled from an IP device connected to said terminal, 
i.e., intermediate the IP network and the terminal. 

According to a third aspect of the invention, a telecommunications system 

3 0 having equipment providing telephony connections as well as telephony-related 

features accessible to a plurality of telephones connected as extensions thereof, 
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said equipment for connection to a public switched telephone network (PSTN), 
further comprises an internet protocol (IP) relay device (10) connected as at least 
one extension of said equipment for converting at least voice and signaling 
between said PSTN and one or more IP devices (18, 20, 26) in communication 
5 with said IP relay device over an IP network, said one or more IP devices for 
providing a remote access signal to said IP relay device over said IP network for 
accessing said of features said equipment as said at least one extension. 

According further to the third aspect of the invention, said remote access 
signal is a remote hookflash signal that is relayed from said IP relay device to 
10 said equipment. The remote hookflash signal may be initiated at a terminal 
connected to one of the IP devices 
2 According still further to the third aspect of the invention, said accessing 

?i said equipment is for accessing a POTS terminal (30) of said PSTN. 

^ Still further in accord with the third aspect of the invention, said accessing 

S 15 said equipment is for accessing a POTS telephone (30) over said PSTN network 

from a terminal connected to one of said IP devices. 
H According to a fourth aspect of the invention, a gateway, comprises 

means responsive to a remote hookflash signal from a remote device over an 
in internet protocol (IP) network for providing said hookflash signal in a non-IP 

O 2 0 format to equipment connected to a public switched telephone network (PSTN) 
for providing telephony connections as well as telephony-related features to 
telephones connected to said equipment; and means responsive, subsequent to 
said hookflash signal, to an access code from said remote device over said IP 
network for providing said access code to said equipment in a non-IP format 

2 5 indicative of a feature provided by said equipment to extensions thereof whereby 

said gateway enables said remote device to gain access to said feature remotely 
over said IP network. . 

The present invention permits remote offices to connect as off-premise 
extensions of non-IP equipment offering features in addition to simple telephony 

3 0 connections, such as a PBX/centrex/KTS/EKTS/hybrid equipment connected to 

the PSTN and to thereby effectively exploit IP telephony technology. Because 
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remote users appear to the PBX/centrex/KTS system as extensions, they have 
access to all the PBX/centrex/KTS system's extension features. It is a key 
building block for allowing seamless integration of the IP telephony features with 
PBX or PSTN-based features. 
5 These and other objects, features and advantages of the present invention 

will become more apparent in light of the detailed description of a best mode 
embodiment thereof, as illustrated in the accompanying drawing. 

BRIEF DESCRIPTION OF THE DRAWING 
10 Fig. 1 shows a typical environment in which the invention is shown used 

as an exemplary two-line PBX gateway to provide voice over IP service to 
remote locations. 

Fig. 2 shows a series of steps of a method initiated by a remote user to 
^fl access PBX/KTS features available on the PBX/KTS systems of Fig. 1 , for 

ii 15 instance. 

yy 

^ Fig, 3 shows a gateway (IPRelay) that enables a remote IP device to gain 

access to a service of a non-IP PBX as an extension thereof. 

m BEST MODE FOR CARRYING OUT THE INVENTION 

p 2 0 Fig. 1 illustrates a typical environment that a device 10 such as a two-line 

PBX gateway (IPRelay) to provide voice over IP service to remote locations. In 
the scenario shown in Fig. 1 , the PBX gateway (IPRelay) is set up as two clients 
of a Call Processor Server (CPS) 12 and is connected to a PBX 14 as two 
phones. The PBX sees each line as a phone with extension numbers 7150 and 
25 7151 respectively and the CPS sees the gateway (IPRelay) as two clients and 
respectively assigned each gateway line the CPS extensions 2000 and 2001. 

A Telephone System (KTS) 16 has a device 18 called IPShuttle connected 
to it via two analog phone lines using a RJ-1 1 POTS interface to the KTS and a 
RJ-45 interface to a local LAN or to the Internet via a cable or xDSL modem (not 
3 0 shown). A key telephone system (KTS) is generally a smaller version of a PBX 
that gives direct access to the telephone lines. Traditionally, key systems are not 
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switches, and a user manually presses a button on the telephone to select a 
specific central office line to engage. The IPShuttle device 18 has been assigned 
CPS extension 6000 to line 1 and 6001 to line 2. A second, standalone IP 
shuttle device 20 has been assigned CPS extension 2002 to line 1 and 2003 to 
line 2 for connection to a pair of POTS terminals 22, 24 (analog telephones). An 
IPCourier telephone device 26, which is an IP-ready telephone, is assigned 
extension 2004. Various call establishment scenarios will now be discussed. 

The procedures for IPCourier device 26 or an IPShuttle device 18, 20 to 
call a PBX or PSTN phone are exactly the same. Suppose that the user of the 
IPCourier device 26 at extension 2004 wishes to call a PBX phone 28 at 
extension 7153 as shown in Fig. 1 or a PSTN number 555-1212 assigned to a 
POTS telephone 30 connected to the PSTN which is in turn connected to the 
PBX. In this scenario, for instance, the user of the IPCourier device 26 places a 
call to one of the IPRelay device 10 extensions, e.g., extension 2000. Upon 
receiving the incoming call, the IPRelay device 10 automatically goes off hook 
and in turn answers the incoming call. At this point, the IPCourier device 26 has 
established a connection and opened a UDP (User Datagram Protocol) audio 
channel with the IPRelay device 10. When the IPRelay device 10 went off hook, 
it drew dial tones from the PBX 14 and the dial tones were transmitted via the 
audio channel to the IPCourier device 26 and hence to the user. When the user 
hears the dial tones, he or she then dials the PBX extension 7153 or the PSTN 
number 555-1212. As the digits are being dialed, the IPCourier device 26 
detects the DTMF tones and formats them into Q.931 information messages 
which are then transmitted via the CPS 12 to the IPRelay. Q.931 is a message- 
oriented signaling protocol, also called ITU-T Recommendation 1.451. Upon 
receiving the Q.931 information messages, the IPRelay device 10 regenerates 
the DTMF tones and sends them to line 1 , the line that is connected to PBX 
extension 7150, which in turn dials the PBX extension 7153 or the PSTN number 
555-1212. When PBX phone 28 at extension 7153 or POTS phone 30 at number 
555-1212 is ringing, the ringing tone is transmitted from the PBS/PSTN via the 
IPRelay device 10 to the IPCourier device 26 and then to the user via the audio 




channel. Similarly, if PBX phone 28 at extension 7153 or phone 30 at number 
555-1212 is busy, the busy tone is then sent from the PBX/PSTN via the IPRelay 
device 10 to the IPCourier device 26 for the user via the same audio channel. 
When PBX phone 28 at extension 7153 or POTS phone 30 at PSTN number 
5 555-1212 is answered, the conversation between the user of the IPCourier 
device 26 and the PBX user of phone 28 or 30 is packetized and exchanged 
between the IPCourier device 26 and the IPRelay device 10 over the audio 
channel. 

If the user of the IPCourier device 26 initiates the call termination and 
10 sends a release message via the CPS 12 to IPRelay device 10, the IPRelay 

device 10 will automatically go on hook upon receipt of the release message 
5 which completes the call tear down with the CPS 12. The IPRelay device 10 on- 

^ hook action triggers the PBX 14 to disconnect the IPRelay device 10 from the 

p PBX phone 28 at extension 7153 or the POTS telephone 30 at PSTN number 

g 15 555-1212. If on the other hand, the PBX 14 or PSTN user at telephone 30 

initiates the call termination, phone 28 at extension 7153 or phone 30 at number 
1-^ 555-1212 then goes on-hook, and in this case since IPRelay device 10 is still off 

jjf hook, the PBX 14 then presents a dial tone to the IPRelay device 10. Upon 

detecting the dial tone/special tone/inactivity time out (programmable for different 
O 20 PBX/KTS system with default being inactivity timeout), the IPRelay device 10 

automatically sends a release message to the CPS 12 and then goes on-hook. 

The CPS 12 in turn sends a release message to the IPCourier device 26 to 

complete the call tear down. 

Having described the IPCourier device 26 or IPShuttle devices 18, 20 of 

2 5 Fig. 1 calling the PBX phone 28 or PSTN phone 30, the reverse of a PBX phone 

28 or PSTN phone 30 calling the IPCourier device 26 or an IPShuttle device 18, 
20 will now be described. Actually, the procedures for a PBX or PSTN phone 28, 
30 calling the IPCourier device 26 or IPShuttle device 18, 20 can be exactly the 
same as previously described. Suppose for example that the PBX phone 28 at 

3 0 extension 7153 or PSTN phone 30 at number 555-1212 is calling the IPCourier 

device 26 at extension 2004. In this scenario, the user of PBX phone 28 at 
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extension 7153 dials 7150 or the PSTN user of phone 30 dials 214-7150 (214 is 
the dialing prefix for PBX 14). Upon detecting ringing, the IPRelay device 10 
automatically goes off-hook to answer the PBX or PSTN inconning call. The off- 
hook action triggered the IPRelay device 10 to send a setup message to the CPS 
5 12 and the CPS then informs the IPRelay device 10 to provide a dial-tone by 
sending the IPRelay device 10 a Q.931 PSTN information message. At this 
point, the user of PBX phone 28 at extension 7153 or PSTN phone 30 at number 
555-1212 should hear the dial tone and can then dial the IPCourier device 26 
extension 2004. As the digits are being dialed, the IPRelay device 10 detects the 
10 DTMF tones and formats them into Q.931 information messages and sends them 
to the CPS 12 so that it can dial the IPCourier device 26. If the IPCourier device 
kD 26 is busy, the CPS 12 sends a Q.931 PSTN information message to the 

uJ IPRelay device 10. OthenA/ise. it sends the IPRelay device 10 an alerting 

^ message and then a Q.931 PSTN information message. The IPRelay device 10 

m 15 provides to line 1 (connecting to extension 7150) a busy tone upon receiving the 

nj 

i." Q.931 PSTN message or a ringing tone upon receiving an alerting and 

l: accompanying Q.931 PSTN information message. If the user of IPCourier 

U device 26 user answers the call, the IPCourier device 10 then sends a connect 

i message to the CPS 12 to accept the call. The CPS 12 then sends a connect 

□ 2 0 message to the IPRelay device 10 which then stops providing the ringing tone to 
the PBX phone 28 at extension 71 53 or the PSTN phone 30 at number 555- 
1212. At this point, a UDP audio connection is established between the IPRelay 
device 10 and the IPCourier device 26 and a conversation between the user of 
IPCourier device 26 and the user of the PBX phone 28 at extension 7153 or the 

2 5 PSTN phone 30 at number 555-1212 is established. The call tear down follows 

the same procedures as previously described. 

Now suppose that a user of a KTS phone 34 user wants to place a call to 
PBX phone 28 at extension 7153 or PSTN phone 30 at number 555-1212. When 
the user of KTS phone 34 goes off hook and presses a button that corresponds 

3 0 to appearance 6000, the KTS IPShuttle device 18 detects off hook on line 1 in 

the same fashion as the IPCourier device 26 does for the previously explained 
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examples. Thereafter, the rest of the procedures are the same as described 
previously for an IPCourier device 26 initiated call. 

A similar scenario, suppose that the PBX phone 28 at extension 7153 or 
PSTN phone 30 at number 555-1212 is calling the KTS IPShuttle device 18 line 
5 1, which has extension 6000. The procedures between the KTS IPShuttle device 
18 and the IPRelay device 10 are the same as between the IPCourier device 26 
and the IPRelay device 10 as previously described for a PBX or PSTN phone 28, 
30 calling the IPCourier device 26 or IPShuttle device 18 (see above). The 
difference is that IPCourier device 26 rings its phone and the KTS IPShuttle 
10 device 18 rings line 1 which indirectly rings KTS phones 34, 36. The KTS user 
can then use any of the phones 34, 36 to answer the call by pressing the button 
^ that is associated with appearance 6000. 

The previously described scenarios required two step dialing wherein the 
^ user must dial the IPRelay device 10 first, wait for the connection to be 

2 15 established and then dial the destination number. To reduce the two step dialing 

process to a single step of dialing, a hot-line feature can be introduced. For 
H example, IPRelay device 10 can hot-line with the KTS IPShuttle device 18, that is 

Ll configure line 1 of the IPRelay device 10 automatically to dial line 1 of the KTS 

y IPShuttle device 18 and line 2 of the IPRelay device 10 to automatically dial line 

O 20 2 of the KTS IPShuttle device 18 or other IPShuttle device 20 or IPCourier device 
26. In the case of a hot-line from the IPRelay device to the KTS IPShuttle device 
20, then the KTS IPShuttle device 20 may want to register with the CPS 12 as 
7150 and 7151 to match the PBX extensions of IPRelay device 10 just 
mentioned. In this scenario, when the PBX phone 28 user calls 71 50 or the 

2 5 PSTN phone 30 user calls 214-7150, line 1 of the IPRelay device 10 will be rung 

by PBX 14. Upon detecting the ringing tone, the IPRelay device 10 automatically 
goes off hook and dials the CPS 12 extension 7150. which is line 1 of the KTS 
IPShuttle device 20 because of the above-mentioned registration. If "7150" is 
busy, the CPS 12 will inform the IPRelay device 10 by means of the Q.931 PSTN 

3 0 information message to provide a busy tone. If "7150" is ringing, the CPS 12 will 

send an alert and a Q.931 PSTN information message to the IPRelay device 10 
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to play the ring-back tone. The busy or ring-back tone is then fed back to the 
user of PBX phone 28 or PSTN phone 30. If the KTS phone 34, 36 user answers 
the call, then the conversation between the KTS phone 34 or 36 user and the 
PBX phone 28 or PSTN phone 30 user is packetized and exchanged between 
5 the KTS IPShuttle device 18 and the IPRelay device 10 over the UDP audio 
channel. Call tear down follows the same procedures as described previously. 
Similarly, the two-step dialing process can be eliminated for users of the 
IPShuttle device 18 and the user of the IPCourier device 26 by configuring them 
to hot line with the IPRelay device 10. 
10 Besides allowing the above-mentioned call establishment between a 

traditional PBX or KTS (centrex or hybrid system) and remote telephones 
3 connected to them via the Internet or an Intranet using a packetized channel as 

f1 described above, it will also be advantageous according to the present invention 

^ to give access to features of the PBX, centrex or KTS systems to these remote 

m 15 users. Lately, hybrid equipment has been offered which falls into categories of 

both a key system and a PBX, and such hybrids offer features traditionally 
M offered on PBXs only. But these features are, of course, not accessible to IP 

network users. However, according to the present invention, this can be done 
U] with a remote hook flash feature which allows a user with an IP terminal such as 

□ 20 the IPCourier device 26 of Fig. 1 or even a POTS phone 22, 24 such as those 
shown in Fig. 1 connected to an IPShuttle terminal adapter device 20 to access 
the features available on an existing non-IP based PBX, centrex, KTS or hybrid 
systems. This remote hook flash feature allows an IP telephony user to use 
features available on a non-IP based PBX, centrex, KTS or hybrid system which 

2 5 otherwise is impossible. This allows investments in traditional PBXs, centrex, 

KTS or hybrid systems to be upgraded to permit deployment of IP telephony 
solutions. 

Referring now to Fig. 2, a sequence of steps is shown as an example of 
how to carry out a method according to the remote hook flash of the present 

3 0 invention. The remote hook flash is initiated from one of the remote users shown 

in Fig. 1, e.g., a POTS phone 22, 24 or an IPCourier desktop telephone device 
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26. Suppose it is one of the POTS telephones 22, 24 shown in Fig. 1 connected 
to one of the lines 2002, 2003 connecting via the IP shuttle device 20 to the 
Internet or Intranet shown, that wishes to use some features supported by the 
PBX 14. For instance, the PBX 14 might support a speed dial feature. It should 
5 be realized that the discussion that follows is also applicable to a KTS system, a 
hybrid system, or a centrex system with such a feature that can be made 
accessible to IP terminals, according to the present invention. 

One of the POTS telephones 22, 24 connected to the IPShuttle device 20 
via one of the lines 2002 or 2003 goes off hook and a call is established as 
10 shown in Fig. 2(a) between the IPShuttle device 20 and the IPRelay device 10 
with a dial tone being sent from the PBX 14 to the IPRelay device 10 which in 
J turn converts it to a packetized version thereof for the IPShuttle device 20 which 

in turn reconverts it back to a POTS dial tone for one of the POTS telephone sets 
^ 24, 22 on line 2002 or line 2003. 

5 15 As shown in Fig. 2(b), at this point, the user of the POTS telephone 22 or 



24 wishes to indicate a desire to access the speed dial feature by initiating a 
hook flash procedure. This just means that the user will momentarily depress the 
switch hook. It will be similarly accomplished by hitting a flash button on a 
telephone so equipped. The user also presses a key such as the pound key (as 



p 2 0 shown) or some other key sequence (including, e.g., 0-9, *, and #) following the 



hook flash. This key sequence or key is arbitrary and could be user configurable. 
For the IPCourier device 26. the activation mechanism can be a single 
configurable appearance key or special button that is built into the desktop 
phone. 



channel existing between the IPShuttle device 20 and the IPRelay device 10 as 
shown in Fig. 2(c). At this point in time, such has to be a proprietary 
implementation because there are no standards existing for such a feature. But 
it is possible In the future that an open standard could be defined. Sending a 
3 0 control message (for instance an RTP audio packet with a special header) from 
the IPShuttle device 20 to the IPRelay device 10 connected to the PBX 14 (end 



25 



The IPShuttle device 20 then sends a control message via the audio 
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point-to-end point) is the most straightfonA/ard implementation. The end point 
could also be defined as an IP client terminal such as the IPCourier device 26 
shown in Fig. 1 . Altematively, a control message (Q.931 ) could be sent to a 
gatekeeper and then the gatekeeper would forward the control message to the 
IPRelay device 10 or IPShuttle device 20. This would be required if the 
gatekeeper wanted to process the control message. In-band signaling could be 
used but it is currently viewed as disadvantageous because a DSP filter would be 
required (extra CPU processing required) and some codecs may have lossy 
compression. 

Referring now to Fig. 2(d), the hook flash then is signaled from the 
IPRelay device 10 to the PBX 14. The user can then enter feature access codes 
as shown in Fig. 2(e) which are converted in the IPShuttle device 20 (or in the 
IPCourier device 26), sent to the IPRelay device 10 and thence onward to the 
PBX 14 for providing the feature to the remote extension. Besides speed dial, 
other features such as call forwarding can be implemented among others that will 
be known to those of skill in the art and which would normally be provided from a 
PBX, centrex or KTS system. 

Fig. 3 shows a gateway such as the IPRelay device 10 of Fig. 1 that 
enables a remote IP device 20, 26 to gain access to services of a non-IP PBX 
14. It is responsive to a hook flash signal on a line 50 from a remote device 20, 
26 which has been initiated by a user at the device 26 or at a device 22. 24 
connected thereto. The remote hook flash signal on the line 50 is packetized in 
an IP format and provided to a hook flash converter 52 which converts it to a 
non-IP format signal on a line 54 which is provided to the PBX 14 as controlled 
by a control module 56. 

Following the remote hook flash, the user will enter an access code which 
is also provided through the internet or intranet of Fig. 1 in an IP format on a 
signal line 58 to an access code converter 60 also controlled by the controller 56 
for converting of the access code to a non-IP format and for providing same on a 
signal line 62 to the PBX 14. From the point of view of the PBX, the user 
initiating the remote hook flash and access code is just a non-IP extension and is 



now ready to provide the requested service to and fronn the rennote device. This 
can be accomplished over a service converter which converts non-IP signals on 
a line 66 from and to the PBX and likewise signals on a line 68 to and from the 
remote device. In this way, the gateway of Fig. 3 enables the remote device to 
5 gain access remotely to services of the PBX over an IP network. 

To enable seamless integration of the IP telephony network features and 
PBX/centrex/KTS features, the access code converter 60 of Fig. 3 of the IPRelay 
device 10 shown in Fig. 2 can be used. The IPCS 38 of Fig. 1 can be used to 
configure the access code converter 60. IPCS 38 is an IP telephone network 
10 management server. It allows for user configuration of IP telephony devices. 
Then IPRelay device 10 can do feature access code mapping to the PBX 14 so 
that the PBX (or centrex or KTS) can understand the user-configurable code. 
This feature allows the users to configure their own access codes to the features 
on the PBX. An end-point such as the IPRelay device 10 maps the user codes 



m 15 into codes that the PBX, centrex or KTS system understands. Access codes 
can, for instance, be any combination of DTMF keys (0-9, *, #). 



Each IP telephony device has an access code converter similar to access 
code converter 60 in Fig. 3. All feature access codes for IP telephony network 
features can be filtered at the IPShuttle device 20 (or in the IPCourier device 26), 



Q 2 0 or by the IPRelay device 10, and then forwarded to the IPCS 38 in Fig. 1 which 
manages such features. All feature access codes for the PBX/centrex/KTS are 
processed by the IPRelay device 10, as described above. This mapping of 
features to the IP telephony network or PBX/centrex/KTS is transparent to the 
end user of devices 22, 24 or 26 of Fig. 1 . 
2 5 Although the invention has been shown and described with respect to a 



best mode embodiment thereof, it should be understood by those skilled in the 
art that the foregoing and various other changes, omissions and additions in the 
form and detail thereof may be made therein without departing from the spirit and 
scope of the invention. 
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